fix(tui): scope Pages to the selected project, and make Flows show Playbooks - #61

… vendor key

Closes the blocker on every product built from playbooks (#181926). Found by
running `iris lexicon conflicts` end to end for the first time — the sweep ran,
then the assess step died on "OpenAI API key is missing".

There were two AI rails in one CLI. `iris mint scan` posts to
/api/v6/openai/chat/completions with the user's IRIS auth and needs no vendor
credential. Every playbook `mode: prompt` step went straight to @ai-sdk/openai,
which reads OPENAI_API_KEY from the local environment. That is fine for whoever
authored the playbooks and fatal for anything sold on them: a firm installs the
CLI, authenticates, runs `iris lexicon demand 123`, and is told to set a vendor
key the product never mentioned and their IRIS auth already covers.

The proxy is now the default rail. The direct rail is kept as a FALLBACK rather
than removed, so nobody relying on their own key loses anything, and
IRIS_AI_DIRECT=1 forces it.

THE PROXY NAMESPACES MODELS AND 404s BARE NAMES. Probed before building on it:
`gpt-4o-mini` -> 404 "Model not found", `iris/gpt-4o-mini` -> 200. All 19 AI
steps in the tree declare the bare form (11 gpt-4o-mini, 6 gpt-4.1-nano, 2
${{args.model}}), so the name is normalised to `iris/` here and every existing
playbook runs unchanged. The direct rail strips the prefix again, since the
vendor SDK has never heard of it.

A 401/403 from the proxy is treated as "not signed in here" and falls through to
the direct rail; other statuses are reported. When neither rail is available the
error names BOTH and says what to do — "OpenAI API key is missing" sent people
looking for the wrong fix entirely.

VERIFIED with the vendor keys explicitly unset:
  env -u OPENAI_API_KEY -u ANTHROPIC_API_KEY iris lexicon conflicts "…" -y
  -> assess produced a real conflicts sheet through the proxy
  IRIS_AI_DIRECT=1 with no key -> names both rails and the fix
Suite 659 pass / 0 fail across cli/cmd and skill.

Refs #181926, #181888

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

…nd that none of them email by default

The recipe taught `iris bloqs invite` (15 mentions) and had ZERO coverage of `add-member`,
`bloq-members invite`, `--notify` or `--send-email` — one of three surfaces, and not the one
most people reach for.

Adds a table separating them, because they are not variants of each other:
  bloqs add-member      grants an EXISTING account access now      emails only with --notify
  bloq-members invite   invites someone to become a member         emails only with --send-email
  bloqs invite          mints a passwordless tokenized LINK        never emails

Two things that surprise people, now stated:

- --notify is IDEMPOTENT, and that is the resend. Re-running add-member --notify on an existing
  member reports 'Permission updated' and sends again. There is no separate resend verb.
- `iris bloqs invite --email` DOES NOT SEND EMAIL. It addresses the link and hands you the URL to
  deliver yourself. A flag called --email on a command called invite that emails nobody is the
  most surprising thing on the page.

The silent default is deliberate — granting access and announcing it are separate decisions — but
it means reading `Emailed:` is part of the job. 'Shared successfully' is not 'they know'.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GjMn3kzkiaNWMrA4REERpu

…collision

Closes #181924. PlatformIntegrationsCommand and PlatformRunCommand both
registered `integrations`. yargs resolves that silently in favour of the later
registration, so the whole of platform-integrations.ts became unreachable — and
it claimed four names, `integrations`, `int`, `connect` and `apps`, every one of
which is taken by something else. There was no route to it at all.

Four of its subcommands had no equivalent on the winner and were therefore
CLI-unavailable outright:

    integrations share <id> <bloq-id>   share an integration with a bloq
    integrations unshare <id>           revoke that share
    integrations disconnect <id>        disconnect an integration
    integrations setup-native <type>    create a native API-key integration

They are adopted by PlatformRunCommand and now resolve. The rest of the losing
module overlapped: `list` and `call` are already reachable as aliases of
`list-connected` and `exec`, and both were re-verified by invocation.

NOT ABANDONED CODE, WHICH IS WHY THIS MATTERS. Both files were last touched the
same day, three days before the collision was found, and the losing one's change
was a real bug fix — "read BOTH integration stores — a confident negative hid a
live connection". Someone debugged, fixed and shipped a command nobody could run.

`iris --help` printed TWO `integrations` rows, the unreachable one advertising
"connect, call, share, list, disconnect". Unregistering it leaves one row, and
frees `connect` and `apps` as well: collisions drop 13 -> 9 and the only
two-canonical case is gone.

STILL OPEN, DELIBERATELY NOT GUESSED: the losing `connect` carried --api-key,
--token and --webhook-url, which the surviving `connect` does not have. It may be
covered by `setup` / `setup-native`, or it may be a real gap. Whoever knows which
is canonical should decide; inventing a `connect-native` on a hunch would add a
fifth way to connect on top of connect / connect-direct / setup / setup-native.

GUARD: command-collisions.test.ts asserts no two registered commands claim the
same canonical name — hard rule, no allowlist — and ratchets the 9 remaining
alias shadowings so the count cannot grow quietly. PROVEN TO FAIL: the collision
was re-introduced, the test went 2 pass / 2 fail naming
"integrations: PlatformIntegrationsCommand + PlatformRunCommand", and green again
once reverted. It also asserts the scan resolves >100 commands first, because a
scan that silently resolves nothing passes everything.

Nothing caught this before because nothing was broken in a way a machine watched:
both compiled, both registered, both rendered in help, and the capability index
lists the token once so it could not show a conflict either. Running the name was
the only instrument that could tell the difference.

Index: 1288 -> 1286. The two removed entries are the losing module's `call` and
`list`, which were advertised and unreachable; both still work as aliases.

Closes #181924

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

Covers the mental model first — a page binds an ADDRESS and the storage sits behind it —
then the write-compile-publish-bind loop, server-side search/sort, and the gotchas that cost
real time: pushing from the wrong directory into a stale shadow pages/, embedded artifacts
needing a trusted owner while named ones do not, and the three things that fail silently
(v-html, webfont CDNs, remote url() in CSS).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ote a dead key

#181940 was filed as "the clone is PERMANENTLY gated, there is no route back", then
corrected to "the commands work, the cache made it look like they didn't". Both
readings were close. The actual defect is smaller and worse:

  iris pages set <slug> json_content.requireOtp false

`pages set` writes INTO json_content, so that path addressed
json_content.json_content.requireOtp — a dead key nothing reads. The PUT returned
200. Then the read-back verifier resolved the SAME dead path, found the value it
had just written, and printed "Updated". The instrument agreed with itself, so
half the documented fix never ran and said it had.

That is why the gate looked unliftable: requires_auth was cleared, requireOtp was
not, and fl-api's PageController::update re-derives the column from the key on the
next json write — so the gate came back on its own. Same family as the log window
that caps at 500 lines: a check that cannot tell "applied" from "not measured".

WHAT THIS CHANGES

  normaliseSetPath()   strips a redundant leading `json_content.`. Stripped, not
                       refused — everyone who typed it meant the key inside, and
                       there is nothing else it could have addressed.
  pageGateFlags()      ONE reader for a gate that is two flags with two names in
                       two places. Anything asking "is this gated" while reading
                       one of them is right by luck.
  pages ungate <slug>  the whole fix as one verb: requireOtp first, the column
                       LAST (the reverse order undoes itself), then the purge, then
                       a read-back that checks BOTH flags. It also drops the dead
                       nested key if the old CLI left one.
  pages set            refuses owner_id/owner_type up front and names `reassign`.
                       It used to accept, not apply, and report so afterwards —
                       honest but late. Clearing requires_auth while requireOtp is
                       still set now warns that the server will put it back.
  pages duplicate      already refused a gated OWNER; it read only the column, so a
                       source gated by the json key alone walked through. Now reads
                       both, names which one, and when ownership IS explicit it
                       states the gate it copied instead of shipping it silently.
  pages cache-clear    stopped printing "Verify: <url>" straight after a purge.
                       Propagation is not instant, and that invitation is precisely
                       what produced this ticket's first, wrong root cause.

VERIFICATION. 11 new cases on the two pure helpers, including the one that matters:
the dead nested key must NOT read as the gate. Exercised live — `set
json_content.theme.mode` now reports the strip and writes the real key, leaving no
nested junk; `set owner_id` refuses; `ungate` reports "Already open" on an open
page. 53 existing pages tests still pass. tsc clean for this file.

ALSO CARRIED, AND NOT MINE. A parallel session was editing this same working tree
and its uncommitted work went in with this commit: `check-public`, `publish-html`,
`read`, `verify`, the `--allow-gated-owner` option and the gated-owner refusal in
`duplicate`, plus buildBespokeJsonContent / detectLane / normalizeForMatch /
parseHtmlDocument. My changes build directly on that duplicate refusal, so they do
not separate cleanly, and inventing commit messages for someone else's in-flight
work would be worse than saying this plainly. Those parts are unreviewed and
untested by me. This is the second time this tree has crossed two sessions today —
see fl-api 405c97b4, which swept up a half-finished edit of mine the same way.

Refs #181940

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ce52QvW5TxbbF9AJeb9ge2

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4gU6dUVWHTsXZ4jAB5PRc

…dates

#181940. `pages push` re-asserts requires_auth from the local file — correct, and
the reason it does is #180009: sending nothing let the gate drift silently. But
re-asserting is only right when the local file is CURRENT.

`pages set <slug> requires_auth true` writes the COLUMN. A local JSON pulled
before that change still says false. The next push sends it, and the gate is
gone. That is not hypothetical — it happened here, and an internal page naming
our own unshipped claims sat publicly readable because of it.

Every instrument reported success. `pages set` said "Updated page column
requires_auth = true", `pages push` said pushed, `curl` returned 200 with correct
SEO metadata, and an authenticated browser rendered the page exactly as a public
one would. The only thing that disagreed was `pages check-public`, which fetches
as a stranger — and which already existed while I was building the check by hand.

THE RULE: a push may TIGHTEN a gate freely and may not LOOSEN one from a file
that does not know the gate exists. Fails closed in the one direction where being
wrong is a leak rather than an inconvenience.

The refusal names both values, explains WHY the local copy is probably stale, and
gives three commands: pull to refresh, --force to do it deliberately, and
check-public to confirm either way. A refusal that does not say how to proceed
gets worked around.

PROVEN TO FIRE, then proven not to over-fire. Pulled a genuinely gated page, set
requires_auth=false locally to recreate the exact stale-file case, pushed:
refused, with both values printed. Re-pulled, pushed again: succeeded, published,
and check-public still reports "A stranger CANNOT read this page".

Not fixed here and still true: `pages duplicate` inherits requires_auth and
requireOtp from its source with no warning, which is how the gate arrived on a
page that was never meant to have one.

Refs #181940

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

Ships the regenerated capability index. v1.3.200's tag predated the
capabilities.json commit, so its binary carried a stale index and `iris find`
could not surface pages read/verify/publish-html or the genesis-verify-pages
how-to — the index is bundled into the binary.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4gU6dUVWHTsXZ4jAB5PRc

…e page

A `requires_auth` page served to an unauthenticated fetch returns HTTP 200 with a
fully rendered gate. Every signal read/verify rely on was a normal success —
status 200, a title, real text — so `iris pages read iris-harness-gap-analysis`
printed

  Welcome to IRIS / Instant access — no code, no password / Email address / Continue

as the document, and exited 0. `--min-words 400` would have failed with "52
words", which reads as an EMPTY page rather than one you were never let into, and
`--expect "<a real phrase>"` would have read as CONTENT MISSING rather than NOT
AUTHENTICATED.

That is precisely the defect these commands were written to remove — a check that
cannot tell "broken" from "not measured" — so the gate is now a refusal, like the
404 guard, not a low word count.

Detection uses the Inertia payload's `props.gateRequired`, which is authoritative
(`gateRequired: true, gateBloqId: 570` on the repro), with a narrow copy-based
fallback for a gate rendered outside that payload. Deliberately narrow: an
`input[type=email]` alone is NOT treated as a gate, since a false positive here
would refuse to read a legitimate page.

  --allow-gated  inspect the gate itself; `read` then labels it
                 "GATED (this is the gate, not the page)"

The refusal points at `iris pages check-public <slug>`, which answers the adjacent
question — "can a stranger read this" — that `verify` does not.

Controls run: a public bespoke page and a public composable page both still read
(gated:false), so this is not a false positive on the common path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4gU6dUVWHTsXZ4jAB5PRc

The command exists so nobody has to guess what a stranger sees, and it guessed the
host. `publicUrl(slug)` falls back to freelabel.net, so a page served on heyiris.io
or a client's own domain was checked at an address nobody was ever given — an
instrument built to stop false answers, returning one. Caught on the internal
gap-analysis page, whose real url is heyiris.io; the two agreed there by luck.

Now resolves the page's own public_url first. The lookup is authenticated and is used
ONLY to learn the host — the fetch itself stays credential-free, which is the entire
point of the command. If the lookup fails (not the owner, no key) it falls back to the
default rather than refusing: a checked-at-the-default answer with the url printed
beside it is still honest. `--url` overrides both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

The pre-push route check reported `POST /api/v1/corpus/observe` as an endpoint that
does not exist. It exists — routes/api.php:2961, committed — so the snapshot was
stale, which is the failure this design chooses on purpose: a false positive that
blocks a push rather than a false negative that ships a broken command.

Refreshed from production per script/refresh-routes.sh. 220 routes added, 3,079
total; 1,184 call sites checked, 0 new dead endpoints, the 27 baselined ones
unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

Ships the gate fix: `pages read`/`verify` were returning the OTP gate's own text
as if it were the page (HTTP 200, exit 0), so `--min-words` failed with a tiny
word count that reads as an EMPTY page rather than one you were never let into.
Both now refuse unless --allow-gated, and point at `pages check-public`.

Also carries, from a concurrent session: `check-public asked the wrong host`, and
a refreshed production route snapshot.

Supersedes v1.3.201, whose release run stalled on a scarce macos-15-intel runner
(every other build job green) — 202 contains everything 201 does.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4gU6dUVWHTsXZ4jAB5PRc

`ce2fdf8be` added how-to/genesis-components.md and how-to/genesis-verify-pages.md
and did not add them to scaffold/manifest.json, so the installer had no way to
fetch either one. The pre-push hook has been refusing every push since, which is
the check working — it is just that the person it stopped was whoever pushed next.

Same failure the design-standard entry already records in its own purpose line: in
the repo, absent from the manifest, therefore undistributed. Worth noticing that it
has now happened twice, and that nothing links adding a recipe to registering it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

The pre-push hook refuses a lockfile that disagrees with package.json. It said
1.3.202 vs 1.3.201; regenerated with --lockfile-only, which is the fix the hook
itself names.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

…d nothing

`CROSS_REPO_PAT` expired on 2026-08-20 — a 90-day token minted 2026-05-22 —
and `build-desktop` has failed on every release since. Pinned by bisecting the
run history:

  v1.3.189  2026-08-20 01:46Z  desktop=success,success
  v1.3.192  2026-08-21 17:33Z  desktop=failure,failure   <- first failure

The expiry (2026-08-20 23:23Z) sits dead centre of that window. Eleven releases
— v1.3.192 through v1.3.202 — shipped with no desktop app.

Nobody noticed because the job is `continue-on-error: true`, so its red X neither
gated the release nor carried information: "Bad credentials" on a checkout looks
like any other cross-repo failure, and after the second or third release the job
was simply a light that is always red. It could no longer distinguish "Electron
broke" from "the token died" — the same defect as a grep that cannot tell
"absent" from "not measured".

Check the credential FIRST and name the cause in the run summary. When the token
is dead the remaining steps skip cleanly instead of cascading, so a red
build-desktop once again means a real desktop-build failure. The CLI binaries were
never affected and still are not gated on this.

Preflight verified against the live repo both ways: a valid token returns HTTP 200
(ok=true), a dead one returns 401 (ok=false).

Still required to actually restore desktop builds: rotate the token.
  gh secret set CROSS_REPO_PAT --repo FREELABEL/iris-opencode

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4gU6dUVWHTsXZ4jAB5PRc

…d one

`iris pulse check --sources imessage` matched `m.text LIKE '%kw%'` and nothing
else. Measured on one Mac over seven days: 738 messages, 323 with NULL/empty
text, 318 of those carrying an attributedBody — so it was blind to ~44% of a
real week while reporting `searched: true, hits: 0`. That is the shape rule 1 in
this module's header exists to forbid, broken one level below where the rule was
being enforced: the SOURCE was searched, a structural subset of the ROWS was not.

Attachments were a third place entirely — 58,118 rows in `attachment`, joined
through `message_attachment_join`, never touched. A file named
`RevOps-SaveLifeAI.pdf` could not be found by searching for "revenue ops".

It cost a real document. That PDF sat in ~/Library/Messages/Attachments for nine
hours while `iris search` (bloq/Obsidian/Drive only), `pulse check` (text column
only) and `atlas:comms` (unnamed placeholder) all agreed it had never arrived.

THE OBVIOUS FIX DOES NOT WORK AND FAILS SILENTLY.
`CAST(attributedBody AS TEXT) LIKE '%kw%'` stops at the first NUL byte, and an
NSKeyedArchiver stream has one within its first dozen:

    SELECT length(CAST(x'616263006465662e2e2e' AS TEXT));  -- 3

`replace(blob, X'00', ' ')` fails identically (its args get cast first). The cast
version was written, passed the text and attachment tests, and would have shipped
looking like a fix. The fixture test caught it by asserting on a rich message
specifically. `hex(substr(blob,1,1024))` is NUL-safe and exact, and the match then
happens in JS where it also stays case-insensitive.

sweepImessage is now two passes — SQL for body text and attachment filenames, JS
over the hex for the blob — feeding one map keyed by message id, so a message
that matches twice is one hit. Real data, before -> after:

    revenue operations   0 -> 1
    audible              0 -> 1
    amazon               1 -> 3
    revops               0 -> 1   (as: RevOps-SaveLifeAI.pdf)

Also adds the verb that was missing entirely:

    iris comms attachments [lead] [--search] [--days] [--out <dir>]

Lead-scoped or global; `--out` copies files back out under the names the sender
gave them (collisions disambiguated, never overwritten); `onDisk` is checked
rather than assumed, because a purged or offloaded attachment still has its row;
Apple's `.pluginPayloadAttachment` rich-link rows are excluded by default as
plumbing rather than files.

`lib/imessage.ts` gains `listAttachments()` — the attachment table was already
read there, but only ever behind a vcard filter to harvest contact cards, so
58,118 rows were reachable only if what you wanted was a .vcf.

platform-pulse-check.ts and pulse-check-sweep.ts were untracked while committed
code imported them, which meant main could not be built from a clean checkout.

Five fixture tests against a temp chat.db (text hit, attributedBody hit,
attachment hit, a non-match, and a missing database reporting why). 25 pass.

Refs #181963 #181964 #181990

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VwQFhFiUQeo8HF6XRmgmzu

The position paper's "local developer ergonomics" row could not be claimed in either
direction, because nobody had timed install → auth → browser. So it got timed. Cold
HOME, no ~/.iris, no auth:

    boot → listening    3.1s
    GET /  → HTTP 200   2.66s TTFB
    auth required       none

The ergonomics were never the problem. server.ts ends in a catch-all:

    .all("/*", c => proxy(`https://app.opencode.ai${path}`))

`iris web` opened the browser at `/`, which is upstream's hosted workspace, titled
<title>OpenCode</title>, fetched over the network. One command to a working browser
UI — and not one byte of it ours, local, or offline. That is not a row we can claim
as a differentiator, and it is not one they can claim over us either: it is the same
artifact. Writing it either way would have been guessing, which the gap analysis
says is how the other rows got written wrong.

So: /iris, served locally, and `iris web` opens that.

  TTFB 1.2ms vs 2.66s — the difference between a local read and a round trip
  zero external requests — no CDN, no webfont, verified not assumed
  status / address / version / auth / directory, each degrading to "unknown"
  rather than throwing. A status page that cannot render when things are broken is
  a status page for the case you do not have.

The workspace is one click away at / and is UNTOUCHED. Taking / itself would have
meant serving an SPA shell from a path it was not built for — trading a branding
problem for a broken app.

Registered as a standalone app.get() rather than appended to the 2,800-line Hono
chain: one more link tripped TS2589, "type instantiation is excessively deep".

Render-verified in a browser, not by grepping the response — the cold-state page
correctly shows "not signed in" and offers `iris auth login`.

STILL OPEN (#181991): install itself is unmeasured. Everything above starts from a
built binary. One scripted run on a clean VM finishes the row.

Refs #181991. Transcript gap tracked separately as #181992.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ce52QvW5TxbbF9AJeb9ge2

…e page (#181984)

push re-asserted `requires_auth` from the local JSON, on the reasoning that dropping
a field lets it drift (#180009). That reasoning does not hold for this field:
PageController::update assigns the column only inside
`if ($request->has('requires_auth'))`, so NOT sending it leaves the gate exactly as it
was. Verified against production — pushed content to a gated probe page with the key
removed from the file, and the column read back `true`.

Re-asserting was therefore pure downside, and it collected. A pull wrote
`requires_auth: false` for a page that was provably gated, push wrote that false back,
and an internal document was served publicly for about thirty seconds. Every step
reported success, because every step was telling the truth about itself: pull did pull,
push did push, and neither could know the value being round-tripped was a security flag
that had gone stale between the read and the write.

THE GUARD FROM LAST TIME COULD NOT CATCH IT. #181940's stale-file check compared the
local value against getBySlug() — the SAME endpoint the pull had just read. When that
read is wrong both sides agree and the guard goes blind precisely when it is needed. A
check whose two inputs share a failure mode is not a check, and this one had never
refused anything, so nobody knew.

Now the gate is simply never sent. Changing it has three explicit verbs — `pages set`,
`pages ungate`, and the create path — all of which say what they are doing. A content
push has no business carrying access control, whatever the cache underneath happens to
be doing that minute; removing the field removes the entire class rather than the one
cause I could not reproduce.

When the local file disagrees with live, push says so and names the right verb, rather
than silently syncing in either direction. The file is informational for this field
now, and the reader who believes otherwise is who that line is for.

Replayed the exact leak: local `requires_auth: false`, live gated. Content updated,
warning printed, column still `true`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

…overable

The pre-push check refuses a stale index and named the reason: `atlas:comms
attachments` is COMMITTED and missing from capabilities.json, so nothing that
searches capabilities could find it. A dirty tree does not excuse that, and the
hook says so.

Regenerated: 1,288 commands · 48 how-tos · 59 playbooks · 58 skills = 1,453. The
only content change is that command and its parent's describe.

Third time this shape has blocked a push today — a recipe, a route, now a command,
each committed without the index entry that makes it reachable. Adding the thing
and registering the thing are separate steps, and nothing links them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RbEmt8v94xNZzKKqVXkRwm

The "local developer ergonomics" row sat unclaimable because nobody had timed
install → auth → browser from cold. Not because it was hard. Because it was nobody's.
So it is a script now, and the number has an owner.

Cold machine, isolated HOME, released v1.3.202:

    install                 3.7s
    first run (--version)   1.6s
    auth list (signed out)  0.7s
    serve → listening       1.0s
    ────────────────────────────
    TOTAL cold → browser    9.2s

ISOLATED BY DEFAULT — everything lands in a throwaway HOME, so running it on a real
machine cannot touch ~/.iris, shell config, or LaunchAgents. That is also what makes
it honest: a warm machine measures nothing.

TELEMETRY OFF — the installer emits install_start/install_success (#179077), the
funnel instrument. A synthetic install must not land in it, or the measurement
corrupts the thing it exists to inform.

AND THE PART THAT ALMOST GOT AWAY. The first version checked `GET /iris` for HTTP
200 and reported PASS — on a released binary that has no /iris route. The catch-all
proxies every unmatched path to app.opencode.ai, which serves its SPA for ANY path,
so the front door "existed" with <title>OpenCode</title>. Same failure family as
grepping for a symbol to confirm a deploy: a check that cannot tell the thing it is
measuring from its absence. It asserts the title now, and correctly reports the
current release as NOT OURS until #181991 ships.

Refs #181991

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ce52QvW5TxbbF9AJeb9ge2

… never ran

HEAD did not typecheck. platform-pulse-check.ts registered a `gmail` source that
TOPIC_SOURCES did not declare, so `tsgo --noEmit` failed on a clean checkout.
This adds gmail to the union and lands the tokenisation work that came with it.

THE TESTS THAT "FAILED" WERE NEVER RUNNING. pulse-check-sweep.test.ts used
keywordPattern, sweepDiary and sweepFiles without importing them. All three are
exported; the import line simply omitted them. Under `bun test` they were
undefined, so the two PC-07 assertions compared nothing and reported a mismatch
that looked exactly like an incomplete refactor — Expected 0, Received 2.

I nearly acted on that. The plan was to mark them todo and file a ticket saying
the tokenisation migration was half-done. It is not half-done. Running the two
sweeps directly against the same repo root the test uses gives identical results
for "MAYO — Life Atlas" and "mayo life atlas" — diary 7/7, files 13/13, empty
set difference both ways, and byte-identical patterns. The fix was complete and
the instrument was broken, which is the same shape as the bug this file exists
to fix.

With the import repaired: 34 pass / 0 fail in the file, 521 / 0 across cli/cmd,
typecheck clean.

Also here:
· A non-null assertion on keywordPattern(nasty) in the metacharacter test, matching
  the two lines under it. It returns string | null and RegExp does not take null.
· A 30s timeout on the sweepFiles equality test. It greps every tracked file in
  every repo under the root, twice; it passed alone and blew the 5s default inside
  the full suite. A timeout there reads as a logic failure, which is the most
  expensive kind of false alarm.
· platform-playbook: publish now prints the /playbooks/{name} address, or says why
  there is not one. The address has always worked; nothing returned it, so publish
  reported success and left the caller to conclude playbooks had no web surface.

NOT INCLUDED, deliberately: the mint working-tree changes. They carry a real
argv-mapping failure — `platform-mint.ts · rm <key> · --json`, an option
registered whose handler never reads it — and they are separate work. Verified by
control: argv-mapping is 5/0 at HEAD and 4/1 with those files present.

Refs #181990

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

…source

`iris search` advertised "search everything you have written" and covered bloq
items, Obsidian and Drive. Not messages. Not mail. Searching it for something a
person had texted you returned nothing, and the empty result did not say that an
entire class of source had never been consulted — which is how a 1.4MB PDF in
~/Library/Messages/Attachments read as a document that never arrived. (#181967)

Adds `imessage` and `gmail` as federated sources, in `--include-all` by default
on the precedent set by #180715: a default that quietly omits a source
contradicts the verb's stated contract in the direction nobody checks, because
you get results and therefore believe you searched.

Both searchers DELEGATE to the pulse sweep rather than querying the stores
again. Reimplementing message reading per feature is what made the sweep blind
to attributedBody and to attachments in the first place (#181990), and a third
implementation here would be that same mistake with the lesson still warm.

SOURCE_NAMES replaces three separate literal lists. The type union and those
filters had to be edited together, and nothing enforced it: adding a name to the
union alone compiles while every filter silently drops it — an unrecognised
--source then falls back to the default, which is precisely the failure the
comment above resolveSources warns about.

Also lands `gmail: "Gmail"` in the pulse source labels, and a cold-start retry
for the Apple Mail sweep. Mail.app is driven over AppleScript and fails the
FIRST script handed to a cold Mail — osascript returns "Command failed" and the
bridge surfaces a 500. Every variant that 500'd inside a sweep returned 200 when
re-run by hand seconds later. Without the retry a transient cold start writes off
the whole source for the run: honest under rule 1, useless in practice. One
retry, only for the failure shape that is actually transient.

Verified end to end through the built binary:

    iris search "revops"
      [imessage] 2026-08-22  RevOps-SaveLifeAI.pdf   +14699553570
      [gmail]    2025-10-03  Richard Delgado · Fwd: Email meeting follow-up
      imessage 1 · obsidian ERROR (bridge HTTP 404) · drive 0 · gmail 1

    iris pulse check "technical summit" --sources email,gmail
      10 hits across 2/2 sources   (Apple Mail 5 · Gmail 5 +5)

Refs #181965 #181967

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VwQFhFiUQeo8HF6XRmgmzu

…default

The help text said 'uses Gemini'. Composition runs on OpenAI models and has for
some time — the stale label sent me to the wrong provider while diagnosing
#182042, and it is the first thing anyone reads before running the command.

--model now names the server default (gpt-5.6-luna) rather than 'AI model
override', so the flag is useful without reading the server config.

Refs #182042

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

buildBespokeJsonContent() hardcoded requireOtp:false on the standalone
lane and omitted it on the custom lane, regardless of --requires-auth.
The requires_auth record column locked the page, but every visitor —
including the owner — got the frictionless "instant access, no code,
no password" modal instead of a real emailed code, and that path has
no code to submit at all. Reproduced live on /p/mediguide-boundary:
the owner couldn't get past the email step.

Thread requiresAuth through to requireOtp on both lanes. Verified the
fix by hand-setting json_content.requireOtp on the live page and
running the full send-otp -> verify-otp -> session cycle end to end.

Fixes #182059.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Found while building the RevOps KPI layer on bloq anomalyco#624. `--status` is registered
for every entity in this group and `goals` and `strategies` both persist it. The
`kpis` builder set name, target, current and unit, and dropped status on the
floor — accepted on the command line, reported as success, absent from the
stored record.

It matters more here than the one-line fix suggests. Status is how a KPI layer
distinguishes MEASURED AND ON TRACK from MEASURED AND SLIPPING from NOT MEASURED
AT ALL. Without it, twelve KPIs that cannot be computed yet — no billing source,
no deal amounts, no stage timestamps — store as a bare target with an empty
current, which reads as zero. A metric nobody can calculate and a metric sitting
at zero are opposite facts and looked identical.

Verified by round-trip through the stored business_context, not by the command
echoing back: 17 KPIs, 5 carrying status "live" with real computed values, 12
carrying the specific input each one waits on.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

…_ref dedup, splits, paid-from (#182038, #182035, #182036)

Groups let one budget cap sit on several categories (a shopping trip
splitting across household/groceries/dining had nowhere to land); spend
policy enforces category/description/limit rules before a write, with
`mint doctor` auditing existing rows against it.

Layered on top, for ad spend specifically:
- `mint import --source-ref-col`: dedup by stable external identity instead
  of date+amount+description, so a platform revising a stat mid-day
  corrects the one row it belongs to instead of duplicating it (#182038).
- `mint split <id> --into "a=X,b=Y"`: divide one invoice across several
  categories/campaigns; parts must sum exactly to the total, and the
  parent is excluded from budget totals once split rather than deleted
  (#182035).
- `metadata.paid_from` + `mint paid-from` + `mint reimbursable`: track
  when the paying account differs from the budget scope it counts
  against — a business ad bought on a personal card — without touching
  how budgets are summed (#182036).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EdzJ4y3yKPpg2VG8nL8y45

…as undetectable

#182078. Three behaviours that are each defensible alone: Prospected is hidden by
default (1,944 of the first 2,000 rows), results cap by recency, and the footer
printed only how many were shown. Together, with no population figure, they
produce a confident partial answer indistinguishable from a complete one.

THE TOTAL WAS ALWAYS THERE AND ALWAYS MISREAD. The endpoint is a Laravel
paginator with `total` at the TOP level; the code read `data.meta.total`, which
does not exist, and fell back to `leads.length`. So totalFromApi could only ever
equal the page size, which made `total > shown` impossible and truncation
undetectable BY CONSTRUCTION.

Measured while fixing it: per_page=5 returns total 28522.

WHAT IT COST. I used this command as a measurement instrument and published six
funnel KPIs from it onto bloq anomalyco#624 — lead-to-contact 39.3%, contact-to-qualified
81.8%, win rate 66.7%. Every one was computed over 56 rows out of 28,522, and
reported as measured fact. They were wrong in the FLATTERING direction, because a
truncated sample of WORKED leads looks like a healthy funnel precisely when the
unworked ones are the ones missing. All six are corrected to blocked.

NOW:
    20 lead(s) (62 Prospected hidden — use --all · newest 20 of 28522)

And in --json, the array shape is preserved because callers parse it, so the
caveat goes to STDERR — reaching a human or an agent without corrupting piped
stdout:
    [leads list] TRUNCATED: newest 20 of 28522 by id
    [leads list] FILTERED: 62 Prospected hidden (pass --all)
    [leads list] This is a page, not a population — do not compute rates from it.

A silent truncation in JSON is the exact failure this exists to prevent.

Refs #182078, RevOps epic #182075

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BZagd8eJFQz593QjSkVG4u

…other bloq

Fixes #182063 (CLI half — server fix in fl-api 8a5d7195, already deployed).

A schema slug is unique per (user, bloq), not per user — ensureCustomerSchema()
mints a fresh 'customers' schema for every bloq the first time its gate is
used, so anyone with more than one gated page has several same-slug schemas.
The server picked whichever it found first for the slug with no way to
disambiguate from this command.

Adds --bloq to `atlas:datasets records list`, threaded to the now-fixed
?bloq_id= param the server actually honors. Also prints which schema id
answered when disambiguation wasn't requested, so the ambiguity is visible
instead of silent.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

SURFACING, not an afterthought. A feature that exists in the binary and nowhere a
human looks reaches nobody — and the capability index is what MCP discovery and
`iris find` read, so a command absent from it is invisible to every coding agent.

  capabilities.json: +hive rent, hive rentals, hive release, hive providers
                     (verified additive — no existing capability removed)
  scaffold/how-to/hive-rent-compute.md: the happy path, start to release

The how-to leads with the distinction that matters — a rental is a machine you
KEEP, not a job that finishes — because everything else about the product follows
from it, including why nothing releases it for you.

It is explicit about what `--no-hive` costs rather than what it skips: installing
the agent is what lets IRIS run work on that machine, so the real choice is about
dispatch, not about whether a CLI gets installed.

And it documents the failed-release message as intended behaviour, because a user
who sees "may still be running and billing" needs to know that is the tool being
honest rather than broken.

Refs #183399

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DezvuWKN7k5zUBtJ44ZZM9

Picks up /api/v6/compute (providers, index, store, destroy) — live and verified —
plus the reachr service-packages endpoint another session's commit called, which
the stale snapshot was flagging as dead.

3112 routes, read from production rather than assumed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DezvuWKN7k5zUBtJ44ZZM9

…, with provenance

GET /api/v1/bloqs/{}/service-packages is called by offers.ts (from the reachr
commit 4147af8) and no route serves it. Verified dead rather than assumed: a
routes snapshot read from PRODUCTION contains 0 matches, so it was never deployed.

Baselined ONLY to unblock an unrelated push (the #183399 compute CLI). The entry
says so in its `why`, because the baseline file's own note is that every entry is
a real defect and the list must shrink — an entry without provenance becomes
permanent by default.

Filed separately so it is tracked rather than buried.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DezvuWKN7k5zUBtJ44ZZM9

…ips it

A how-to that is not in the manifest is never fetched by the installer — it
exists in the repo and reaches nobody, which is the exact failure the surfacing
checklist exists to catch. The pre-push hook caught it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DezvuWKN7k5zUBtJ44ZZM9

Epic #182840.

CTX-2 — `triggers` in playbook frontmatter.
  `iris playbook remote` has had a --triggers option for a while; local playbooks had no
  matching frontmatter field, so parsePlan never read one and neither publish payload could
  carry it. The gap was the middle of the pipe, not either end.
  Parsed with the same freeform shape as `industries` (list or bare string, no taxonomy),
  surfaced in `playbook show` next to the description — the two are easy to conflate, and
  the distinction is the point: description is WHAT this does, triggers are WHEN to reach
  for it. Both publish paths now send it.

CTX-0b — `by_surface` in `iris usage`.
  Renders calls / avg-in / max-in / cost per surface. avg-in is the column that earns the
  table: total tokens cannot distinguish a bloated system prompt from a long answer, and a
  surface whose avg-in dwarfs its avg-out is paying for context nobody asked for on every
  turn. Server side ships in fl-iris-api.

Verified: parsePlan returns the 3 triggers from health-check's frontmatter, and [] (not
undefined) for a playbook that declares none — absent and empty must stay distinguishable.
platform-usage.ts builds clean. Full-repo typecheck was not run; it exceeds the time budget
here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uymnb8WBqFhZx1oBg2n3m5

…rver ignored

Epic #182840 / CTX-0b. Server side lands in fl-iris-api.

`--surface` narrows SPEND to one product surface (command_bar | react_loop | heartbeat |
proxy | transcription). It is a different axis from `--source`, which narrows ACTIVITY to
who invoked IRIS (cli | mcp | installer), and they stay separate: collapsing them would let
`--source cli` report zero spend, which reads as "the CLI is free" rather than "that word
does not exist on this axis".

The guard is the point. An older IRIS API does not know the `surface` query param, ignores
it, and answers 200 with the same field names and entirely plausible totals — so a filtered
call and an unfiltered one are indistinguishable, and the number gets quoted as one
surface's cost when it is the whole account's. The response now echoes `surface_filter`;
when it does not match what was asked for, the command says the filter was not applied
instead of printing a confident wrong answer.

That failure — a request that silently succeeds as something else — is the same shape as
the rest of this epic, and it is why CTX-0's prompt size had to be derived from source
rather than read from the store that already held it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uymnb8WBqFhZx1oBg2n3m5

…ds it

`iris meetings` was Wispr-only, so every rabbit R1 recording sat in a mailbox
doing nothing. The note the R1 sends is already the shape the command wants:
a structured summary, then `[m:ss] Name: text`. So this is a source adapter,
not a second command — summarise, file on a bloq, feed lead intel, all unchanged.

Reads the local Apple Mail store directly (lib/apple-mail.ts) rather than through
the bridge, because the bridge daemon has no Full Disk Access and every mail call
through it 500s today (#180412). The CLI runs in the user's terminal and inherits
that grant. Envelopes from Mail's SQLite index, bodies from the .emlx files —
never the `summaries` preview, which is capped at 1000 chars (#183189).

Three things the real mail forced:

NOT EVERY MAIL FROM THE R1 IS A MEETING. "Your Magic Gallery Photo" comes from the
same address. The discriminator is a Transcript section with at least one
timestamped line, so a photo notification cannot file itself as a meeting.

THE R1 NAMES SPEAKERS. Observed live: "Arthur", "Clayton", "Alex" — not Speaker 1.
A name is an attribution and a wrong one assigns a commitment to someone who never
made it, which is worse than no label because it reads as certain. The header says
the names are rabbit's guess; --speaker relabels by name as well as by id.

ITS COVERAGE CAVEAT IS THE INVERSE OF WISPR'S. Wispr records system audio and warns
your own mic may be missing; the R1 captures the room including you. Each source
writes its own provenance header — a caveat that is wrong outlives the session.

Also: --ingest files everything new in the window, idempotent on a marker written
into each item so cron can run it. It defaults to rabbit, not all: Wispr records
continuously, so bulk-filing "all" would publish voicemail and personal calls onto
a shared bloq. Sweeping those in has to be asked for by name. --dry-run resolves
nothing, because resolveMeetingsList CREATES the list and a dry run must not.

Filing used ~/.iris/config.json default_bloq_id, which is wrong twice over.

It belongs to `iris announce` — that key points at a release board, so meetings
would land in with release chatter. And it is per MACHINE. This laptop signs in
as two accounts, so one machine-wide destination files one account's meetings
onto the other account's board. A meeting transcript is the last payload you want
misrouted: it can carry a whole client conversation.

So the bloq is the PROJECT and the caller picks it — explicit --bloq, else this
account's remembered choice (~/.iris/meetings.json, keyed by user id), else an
interactive picker whose answer is remembered. The list stays a convention
("Meetings", created on demand) so only one thing is ever decided.

The first explicit --bloq seeds the default; later ones do not overwrite it,
because filing one meeting to a client's board is a one-off, not a new home for
everything after it.

No auto-create fallback, deliberately. Elsewhere in this CLI a missing destination
invents a bloq and files into it. For a transcript that can carry client
conversation or PHI, a run that does not know where to put it must stop and say
so instead of picking somewhere plausible. Non-interactive with nothing remembered
is an error, not a guess.

`--file` files a single meeting to that destination. A bare `iris meetings <id>`
stays a read: prompting for a destination there would answer a question nobody
asked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

package.json had drifted to 1.3.233 while the release line had already
reached v1.3.235, so the obvious next patch (v1.3.234) was long taken.
script/release computes the next version FROM package.json, so it would
have hit the same collision — the file it trusts is not the source of
truth the tags are.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

The already-filed check keyed on the mail message id alone. rabbit RE-SENDS a
recording as a NEW email with a NEW id, so the marker said "never seen this"
about a meeting already on the board — and filed 'Trial Licensing and Agent
Sandbox Architecture' twice on bloq 639 (items #183297 and #183456).

Now each filed meeting also carries a CONTENT fingerprint, and an ingest skips
on either signal: the id catches a re-run, the fingerprint catches a re-send.

mtime is deliberately excluded from the fingerprint. It is the mail's arrival
time — the one field that DOES change on a re-send — so including it would
reproduce the bug in a new place.

Found while verifying the v1.3.236 compiled binary against real mail: the
verification run is what filed the duplicate. Within-run dedupe was already
content-based and worked; there was no equivalent across runs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

Six conflicts, all the same shape: this branch adds the #183460 content
fingerprint, upstream has the file without it. Took ours in each, so the fix
survives and upstream's changes elsewhere in the file are kept from the
auto-merge. 15 tests green, typecheck clean after resolving.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

The pre-push guard refused the push because the lockfile no longer matched
package.json once upstream's dependency changes merged in. Regenerated with
`bun install --lockfile-only`, which is what the guard asks for — the guard
exists so a lockfile drift is caught here rather than in a release build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

…d its reason

It printed "not implemented on the server" and exited 2, citing #137539. By then the server had
CommsRouter — caps, suppression, channel resolution, the lead_comms write — and
OutreachProgress::onCommLogged() to complete a step from a logged comm. Everything except a door,
which landed in fl-api 9ed5ed63.

So Reachr told you who was owed what, and a person retyped it into `iris mail`. That made the
ledger and the step's completion both depend on somebody remembering to do two things, and a step
marked done by hand is indistinguishable from one that sent something.

  iris outreach-send send <lead-id> --step 3
  iris outreach-send send <lead-id> --step 3 --dry-run

COMPLETION IS NOT SENT AS A FLAG. The step completes because the comm was logged carrying its id,
so a completed step can point at the comm that completed it. `--complete` is deliberately absent —
asserting a send is exactly what this replaces.

THREE OUTCOMES THAT ARE NOT ERRORS, rendered as themselves:

  refused        no reachable channel, suppressed, capped, empty copy. Shown as the reason it is,
                 because "send failed" sends someone to re-check a message that was fine.
  already sent   reported, and it does NOT send again. Saying "sent" would be a lie the ledger
                 contradicts, and a duplicate outreach message is the failure a recipient notices.
  dry run        resolves the channel and shows what would go, writing nothing — so "will this
                 work" is answerable without spending a real message on a real person.

`step_completed` is reported rather than assumed. A comm that logs without advancing the step is
worth seeing at the moment it happens, not discovered later on a sequence that never moves —
so the success path warns loudly when the send worked and the step did not close.

Typecheck clean; 151 pass / 0 fail across test/cli.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019wF7NrsCHAhXRn3ZddtQv5

…rom the tags

Three tickets from tonight's session.

#183472 — meetings printed timestamps with toISOString(), so a recording made at
20:03 local displayed as the next day. Display now uses local time; the ingest
marker and the date stamp keep the stable value.

#183477 — the rabbit source reads the local Apple Mail index, which is a CACHE.
With Mail.app quit, new transcripts sit on the server and the command reports
fewer meetings with no hint anything is missing — indistinguishable from a quiet
week. syncStatus()/stalenessNote() now report when Mail is not running or the
index is hours old, through the existing warnings channel that already refuses to
let a read failure read as "you have no meetings". Live right now on this machine:
"Mail.app is not running and the local index is 21.9h old".

#183470 — script/release computed the next version from package.json, which had
drifted to 1.3.233 while the tags were at v1.3.235, so it proposed a version taken
three releases ago. The collision only appeared at push time, after the bump commit
had already been pushed. It now fetches tags and versions from the highest existing
v1.2.3 tag (excluding desktop-v* and vscode-v*, which also start with v), and says
so when package.json disagrees.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

`iris atlas export` writes to iris-export/ (8.3MB of exported board data here).
It was untracked, and script/release refuses on a dirty tree — correctly, since a
tag captures HEAD — so exporting a board silently blocked the next release until
someone noticed and deleted it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

…erable

The pre-push guard refused because capabilities.json was stale: gate-audit,
shared-checkout-merge, composio-integration and dashboard-standards existed as
skills but were not in the index, so nothing routing off it could find them. A
playbook nobody can discover is a playbook nobody runs.

1343 commands · 54 how-tos · 107 playbooks · 113 skills = 1617 capabilities.
Kept the 70 entries whose source lives on another machine rather than pruning
them from this workspace.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

…t that must remove it

routes:check found one NEW dead endpoint against 3112 routes: POST
/api/v1/reachr/steps/{}/send, called from platform-outreach-send.ts:181 and
served by nothing in fl-iris-api or fl-api. Introduced by 7262965 'outreach-send
send actually sends — the refusal outlived its reason', which means the command
now attempts a send and 404s. That is worse than the refusal it replaced, because
it stops looking broken.

Filed as #183489. Baselined ONLY so the guard keeps failing on new dead endpoints
rather than blocking every push on this known one — the entry says NOT yet fixed
and names the ticket, matching the 28 entries already there. The list is supposed
to shrink.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

…red one

My first pass at #183470 replaced "read package.json" with "take the highest v*
tag" and the dry run immediately proposed v1.18.24 — an eleven-minor jump.

This repo is a fork and still carries upstream opencode tags: v1.18.23 and v1.4.x
sort numerically ABOVE the live IRIS line of 1.3.x. The release line is whatever
was cut most recently, which is a date question, not a number one. Ordering by
creatordate gives v1.3.236, and the next patch is v1.3.237.

The check that caught it was running the dry run and reading the number, rather
than trusting that a fix which looked right was right.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

Item ids are what the rest of the CLI hands you — `bug report` returns one,
`atlas publish` returns one, search lists them — and nothing could read one back.
`atlas get` takes a BLOQ id, so passing an item id there suggested `edit-item`.
Reading three items tonight meant a throwaway script that fetched up to 500 items
from a board you had to already know, then filtered client-side.

The endpoint existed the whole time: GET /api/v1/user/bloqs/list/item/{id} returns
200 with title, list_name, status and content. Only the verb was missing.

  iris atlas get-item <id>                 title, list, status, full content
  iris atlas get-item <id> --content-only  just the body, for piping
  iris atlas get-item <id> --json          the raw record

A 404 reports "no item visible to this account", not "no such item" — the two are
different and only one of them is something this command can know.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

The pre-push guard refused because capabilities.json did not contain the command
added in the previous commit. A verb nobody can discover is a verb nobody runs —
which is the point of #183479, filed tonight about this same surface. 1344
commands now indexed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01W969SbUzXiJkGygnbwUZth

…is feature report` was invisible

`iris feature report` is registered, appears in --help, and carries --reporter-lead, which is
the flag that makes bounty work earn. `iris find "feature request"` returned nothing.

The builder walker follows children matched by /\.command\((?:reg\()?(\w+(?:Command|Group))/ —
an identifier ending in Command or Group. platform-feature.ts declares its subcommand as an
inline object literal, so the regex never saw it and the index held a bare `feature` entry with
no children. A verb that exists, is registered and cannot be FOUND is the exact failure this
index was built to end, surviving in the one shape its own regex could not read.

inlineChildren() brace-matches the literal rather than regexing to a closing brace, because
these bodies contain nested objects — a lazy match stops at the first `}` and truncates away
the option descriptions, which are what make a command findable by what it DOES rather than
what it is called. Inline children are treated as leaves: nothing in the codebase nests a named
group inside a literal, and recursing on the guess would invent paths rather than read them.

SCOPE, measured rather than assumed. Five files use the inline shape, and I first read that as
fifteen missing subcommands. It is one. `how-to`, `identity` and `permissions` were already
fully indexed — they declare named constants too, and my count came from taking each file's
first `command:` string as its top-level name, which is not what it is. Diff of the regenerated
index: one entry added, `feature report`, nothing removed. The fix is general; the hole it
closed was a single command.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NDsGZrjZEh5f2GTtZj9oBK

…output (#183479)

I filed #183479 asking for a verb search, then found one already shipped: `iris
find`, aliased search-commands / capabilities / what-can-i, reading the same
capability index the pre-push guard keeps fresh. It works. I could not find it,
and neither can anyone else, for two reasons:

1. `find` was absent from COMMAND_CATEGORY_MAP, so it appeared in NO categorised
   help — not `iris --help`, not `iris guide knowledge`. Its describe line reads
   "find any IRIS capability by intent", which is exactly the answer to the
   question, and it was invisible.

2. Top-level `search` claimed `aliases: ["find"]`. yargs already resolved `iris
   find` to the real command, so the alias did nothing except make the help
   attribute `find` to content search — actively pointing away from it. Two
   commands cannot both own a name; the loser should not advertise it.

Both fixed. `iris --help` now lists both, distinctly: find searches the CLI's own
verbs, search searches what you have written.

The lesson is the one this session kept repeating: the capability existed and the
cost was discovery. I wrote a script to print a board's lists that `iris atlas
get` already printed, and filed a feature request for a command already shipped.

Ranking is a separate problem — "lists on a bloq" returns `atlas list` and
`boards list` but not `atlas get`. Filed separately rather than bundled here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…cters

`iris find "feature request"` returned nothing, while bounty-os-hunter-journey explains — in
committed, published prose — that a feature request earns and that --reporter-lead is what
decides whether it does. The section is at line 141. The haystack stopped at character 4000.

A fixed window on documents that average 10KB truncated 165 of 209 how-tos, playbooks and
skills: 65% of the corpus was unsearchable and nothing said so. That is the same defect as a
command registered but unreachable, one layer down — the knowledge exists, the path to it does
not — and it is the reason this index was built in the first place.

Stripping fenced code and URLs before indexing is what makes indexing everything affordable AND
better: it removes a third of the bytes and approximately none of the search intent, so the
whole corpus costs +678KB against the old cap rather than the +1.4MB a naive full-body index
would. Precision improves at the same time — `http` went from 84 matching entries to 56, which
is exactly the curl-example noise a search for a real word should never have hit.

Measured, before and after:

  reporter-lead      7 -> 9    (+ bounty-os-hunter-journey, bug-bounty)
  feature request    4 -> 6    (+ bounty-os-hunter-journey, bug-bounty)
  anomalyco#652               2 -> 4    (+ bounty-os-hunter-journey, bug-bounty)
  http              84 -> 56   (URL noise removed)
  the              620 -> 620  (no flood)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… public recipes

The 54 how-tos at heyiris.io/how-to are served to anonymous callers — verified, 200 with no
auth. Five of them carried live records.

`deals` published three real companies with two named contacts, their lead IDs, deal values and
proposal/contract URL prefixes. Lead anomalyco#15336 was checked against the CRM and is a real customer,
so this was not an illustrative example that happened to look plausible — it was a paste of
production output.

`pulse` published four named individuals with their monthly billing, payment status and next due
date, and beneath them OUR OWN revenue: MRR and total collected, exact to the cent. Named paying
customers next to what each of them pays.

`bug-bounty` named two hunters and the amount owed to each. Who is owed what is between us and
them; the doc now says that instead of the numbers, and points at the commands, which are scoped
to the caller.

Replaced with a consistent fictional cast rather than deleted, so every example still reads as a
real session. Contract and proposal tokens are now literal `<token>` rather than truncated real
ones — a truncated secret is still a disclosed prefix.

Four other person-shaped names (Ayesha Usman, Dana Whitfield, Jordan Mayo, Marcus Chen) were
checked and left alone. `iris leads search` is a fuzzy token match and returns near neighbours
for anything, so its hits are not evidence; opening the records showed none of them bears those
names. Over-redacting invented examples would have cost the docs clarity for no gain.

Still outstanding and NOT addressed here, because unpublishing a document is a bigger call than
redacting a line: `pathways-cfo-workflow` and `expose-dataset-api` name real clients and
describe their internal pipelines, and eight recipes instruct the reader to run `railway ssh -s
fl-api`, which no customer can run and which discloses our service topology.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…aybooks

PAGES WERE UNSCOPED (#183541). Scoped to 'Branded Champions anomalyco#607', the Pages tab listed
X-ART's pages and IRIS internals. Every other sidebar tab passes bloq_id; pages passed only
user_id — AND it sat in the load-once block that runs before any project is selected, so it
could never change when you switched projects.

Moved into fetchBloqData with owner_type=bloq&owner_id={bloqId}. That filter already existed:
fl-api's PageController::index supports owner_type+owner_id and its own comment calls it 'a
NARROWING filter applied on top of the scope above, never a widening one'; iris-api's
/v1/pages is a pass-through proxy forwarding the query verbatim.

VERIFIED against production data, because the filter is worthless if pages are not owned that
way: xart-board is owner_type=bloq owner_id=570, and branded-champions is owner_id=607. Note
branded-champions was NOT in the reported screenshot — so other projects' pages were pushing
this project's OWN page off the per_page=50 list. The bug was hiding what you came to see, not
just adding noise.

FLOWS -> PLAYBOOKS. The tab labelled 'Flows' rendered workflows. It now renders playbooks,
fetched per-bloq from /api/v1/bloqs/{bloqId}/playbooks and relabelled 'Playbooks'.

Bloq anomalyco#607 has NO attached playbooks, so a purely-attached list would render an empty tab. It
falls back to the available set (97) — but flagged attached:false and headed 'Available — none
attached to this project'. Silently listing 97 global playbooks under a project header would
have repeated the exact bug being fixed one tab over. The label is the difference between a
scoped panel and one pretending to be scoped.

Removed the workflow detail view's now-dead state (activeWorkflow, workflowLoading,
workflowImported) and the status icon/colour helpers rather than leaving signals nothing can
set — dead state in a reset handler reads as if a detail view still exists.

Typecheck clean (the one remaining error, session/llm.ts TS2589, is pre-existing and
unrelated). NOT render-verified in a running TUI — the API contracts and types are checked,
the pixels are not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0195GD9U29DkMpcjbMUdsuMV